Reengineering to the Web: A Reference Architecture

Reengineering existing (large-scale) applications to the web is a complex and highly challenging task. This is due to a variety of mostly demanding requirements for interactive web applications. Usually high performance is required, old interfaces still have to be supported, high availability requirements are usual, information has to be provided to multiple channels and in different formats, pages should contain individual layout across different channels, styles should be imposed over presentation, etc. To achieve these goals a variety of different technologies and concepts have to be well understood, including HTTP protocol handling, persistent stores/databases, various XML standards, authentication, session management, dynamic content creation, presentational abstractions, and flexible legacy system wrapping. In a concrete project, all these components have to be integrated properly and appropriate technologies have to be chosen. On basis of practical and theoretical experience in the problem domain, in this paper, we try to identify the recurring components in reegineering projects to the web, lay out critical issues and choices, and conceptually integrate the components into a reference architecture. 1. Laying out the Problem Domain Reengineering to the web most often means to develop an interactive web application that is connected to existing legacy components or (partly) replaces them. That is, the legacy application has to be provided with an (additional) interactive web interface that (a) decorates the outputs of the system with HTML markup and (b) translates the (e.g. formbased) inputs via the web browser into the (legacy) system’s APIs. In our experience, the domain of building interactive web applications is often underestimated. Thus, in many upfront designs simplistic architectures and implementation techniques are chosen that lead to severe maintenance problems as the web application evolves. Note that some web applications, developed from scratch, have similar characteristics, therefore, they often face similar maintenance problems as well. In Figure 1 we can see such a simplistic three-tier architecture for interactive, web-based applications. A web user agent, such as a browser, communicates with a web server. The web server “understands” that certain requests have to be handled interactively. Thus, it forwards the request and all its information to another module, thread, or process that translates the HTTP request to the legacy system’s APIs. An HTML decorator has to build up the appropriate HTML page out of the system’s response and trigger the web server to send the page to the web client. Using this simple architecture for a given legacy application, we can derive a simple process model for migrating an application to the web. In particular, the following steps have to be performed in general. Of course there are several feedback loops during these steps, and they are not in particular order: Providing an Interface API to the Web: To invoke a system’s functions/methods and decorate them with HTML markup, we first have to identify the relevant components and provide them with distinct interfaces (which may, in the ideal case, exist already). These interfaces have to satisfy the web engineering project’s requirements. To find such interfaces, in general, for each component there are two possibilities: – Wrapper: Wrap the component with a shallow wrapper object that just translates the URL into a call to the legacy system’s API. The wrapper forwards the response to an HTML decorator or returns HTML fragments by itself. – Reengineered/Redeveloped Solution: Sometimes it is suitable to reengineer/redevelop a given component completely, so that it becomes a purely web-enabled solution. E.g. this makes sense, Web Server incoming request Legacy System Request Decoder call conforming to legacy system’s APIs